Shore Side Data System (600031 and 900823) : new-ssds.mbari.org Setup
This page last changed on Jul 28, 2010 by kgomes.
  1. Pat installed RHEL 5
  2. He created a local lroot account for me.
  3. After talking to IS, in order to mount the Tornado shares properly (AUVCTD, AUVBI, and ssdsdata), we created a domain account named ApacheSSDSRO and I changed the password to something hard to crack.
  4. I went on to new-ssds and created a new user ApacheSSDSRO with the same UID as the domain account (1113) and added the group apache to its membership. 
    # adduser -u 1113 -G apache -b /home -s /bin/bash -p ********** -g apache ApacheSSDSRO
  5. I edited the /etc/httpd/conf/httpd.conf file and changed the "User" line from "apache" to "ApacheSSDSRO" which should run the httpd service as ApacheSSDSRO. This was important so that it's UID will get passed to the network share when serving http requests.
  6. I ran the chkconfig command to make sure httpd started on reboot 
    # chkconfig --level 35 httpd on
  7. I then edited the /etc/fstab file to mount the tornado shares that SSDS needs: 
    /dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
# MBARI mounts
tornado.shore.mbari.org:/vol/vol0/ssdsdata /ssdsdata nfs ro 0 0
tornado.shore.mbari.org:/vol/vol0/AUVCTD /data/auvctd nfs ro 0 0
tornado.shore.mbari.org:/vol/AUVBI /data/auvbi nfs ro 0 0
  8. I created the directories /data/auvctd, /data/auvbi, /data/ssds/generated, /data/ssds/ruminate/xml, /ssdsdata and made ApacheSSDSRO as the owner and apache as the group for these. (including the parent /data directory).
  9. I put in a request to IS to have them restore the /data/ssds/ruminate/xml directory
  10. I downloaded jdk1.6.0_20 from Sun (Oracle's) web site to the Desktop on /root and then ran the .bin executable. It created a directory jdk1.6.0_20 which I then moved to /opt
  11. I created a symbolic link in /opt to /opt/java which pointed to that folder.
  12. I then created symbolic links to all the stuff in /opt/java/bin to links in the /usr/bin directory to put them all on the path 
    ln -sf /opt/java/bin/* /usr/bin
  13. I rebooted here just to make sure everything that I had done to date took:
    1. httpd service started automatically ... yeah!
    2. mounts were successful ... yeah!
  14. Now in order to expose those directories as http shares so people can access them, I created symlinks to those directories in /var/www/html
  15. Once the backup of /data/ssds stuff was done, IS re-enabled the rsync (running on pismo) so that the files from /data/ssds are copied to /ssdsdata/ssds
  16. I downloaded jboss-4.0.3SP1 from jboss.org, unzipped and untarred the file on my desktop
  17. I moved the newly created jboss-4.0.3SP1 folder to /opt
  18. I changed ownership of that directory to ApacheSSDSRO and apache as group
  19. I copied the jboss_init_redhat.sh script from the bin directory in jboss to the /etc/init.d directory and renamed to just "jboss"
  20. I then edited that script and changed: 
    JBOSS_HOME=${JBOSS_HOME:-"/usr/local/jboss"}

    to

    JBOSS_HOME=${JBOSS_HOME:-"/opt/jboss"}

    and:

    JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh -c all"}

    to:

    JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh -b 134.89.2.25"}

    so it will run the default server and it will bind to 134.89.2.25 (this needed to be done because requests to the naming service would return and IP of 127.0.0.1 which would cause clients to barf).

    CAUTION on binding

    Originally, I had assigned the bind to 0.0.0.0 as that was supposed to allow it to bind to all IP addresses associated with the server. Normally this seems to work (and it did for the HTTP stuff), but the JMS clients were still getting 127.0.0.1 as the IP back from the server. This was fixed by setting it to the correct IP address. I have not really pushed on it much, but it could also have something to do with the /etc/hosts file which looks like:

    # Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       new-ssds.mbari.org new-ssds localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6

    Also changed:

    JBOSSUS=${JBOSSUS:-"jboss"}

    to:

    JBOSSUS=${JBOSSUS:-"ApacheSSDSRO"}
  21. I then edited /opt/jboss/bin/run.sh and added the following so that the various HOMES were explicit. 
    export JAVA_HOME="/opt/java"
export JBOSS_HOME="/opt/jboss"
  22. I edited /opt/jboss/bin/run.conf and changed: 
    JAVA_OPTS="-server -Xms128m -Xmx128m"

    to:

    JAVA_OPTS="-server -Djava.awt.headless=true -Duser.timezone=UTC -Xms1024m -Xmx2048m"

    to makes sure it knows it is not looking for a graphics server and that the timezone to use it UTC and the memory it will use it reasonable.

  23. I started up JBoss using the /etc/init.d script and it seemed to start up fine. I could see it from a browser on localhost, but not from another machine (maybe firewall issues?).
  24. I then built and deployed the SSDS application on new-ssds.mbari.org (this is a bit involved and not described here).
  25. I had to install the mod_jk connector as it was not already installed. I downloaded the binary .so file from the Apache connector project and installed in /usr/lib64/httpd/modules. I also renamed it to just mod_jk.so
  26. I then configured mod_jk to server basic port 80 traffic to the SSDS application (see https://oceana.mbari.org/confluence/display/SPEPRJ/Apache+mod_jk)
  27. Then I restarted JBoss
  28. I.S. had to open some firewall ports for me
  29. I then added the jboss script to start up for levels 3 and 5 just like for apache by using: 
    # chkconfig --add jboss
  30. I was promptly hacked again by leaving the jmx-console and the web-console in place. I removed those by shutting down jboss, removing jmx-console.war and the management directory from the the deploy directory, deleting the tmp and work directories and restarting.
  31. As an added security measure, we made root owner of all the files in the jboss directory structure except for the directories listed below which were owned by the process that runs JBoss (ApacheSSDSRO):
    1. JBOSS_HOME/server/default/data
    2. JBOSS_HOME/server/default/tmp
    3. JBOSS_HOME/server/default/work
    4. JBOSS_HOME/server/default/log
  32. I then removed the http-invoker.sar from the deploy directory to remove the HTTP invoker for JNDI, EJB and JMX.
  33. I then removed the jms/jbossmq-httpil.sar from the deploy directory to remove the HTTP Invoker for JMS.
Document generated by Confluence on Feb 23, 2017 15:08